Week 1, Day 2 — Giving Lakeview Logistics a real identity — custom domains & DNS

Day 1 review & subdomain assignment

Quick check-in on Day 1 essentials, then distribute subdomain assignments so every student has their domain name before the lecture begins.

• Ask two or three students: "What is your tenant domain? What is your Tenant ID?" — from memory or Lab Journal
• Confirm all students can log in to admin.microsoft.com before proceeding
• Distribute subdomain assignments — each student receives their subdomain in the format lakeviewlogistics[initials].nw7.nat-acc.ca. Write the format on the board, have students record their specific subdomain in their Lab Journal immediately.
• Frame the context: Lakeview Logistics currently has email addresses ending in onmicrosoft.com — today that gets replaced with something a business can actually use.

How Microsoft 365 uses DNS — and why it's unforgiving

Students know DNS. This lecture focuses entirely on what M365 does with it — the specific records required, why each exists, how the verification handshake works, and the real-world consequences of getting any of it wrong.

• The verification handshake — Microsoft generates a unique TXT record value tied to your specific tenant. Adding it to your DNS zone proves you control that zone. This isn't just a formality — it prevents one tenant from claiming a domain owned by another organisation. Once verified, the domain is locked to your tenant globally.
• What each M365 DNS record actually does — go beyond the record type to the service impact. What breaks if MX points to the wrong priority? What does SPF's -all vs ~all mean for mail delivery? Why does Autodiscover matter for end users on day one? What's actually happening when Teams uses the SIP SRV records?
• Subdomains as M365 domains — M365 treats lakeviewlogisticsjd.nw7.nat-acc.ca as a fully qualified domain for all purposes. User UPNs, email addresses, and SharePoint URLs will all use it. The fact that it's a subdomain rather than a root domain is transparent to M365 and to end users.
• Default domain vs primary domain — the verified domain becomes the default for new user accounts. The onmicrosoft.com domain is permanent and cannot be removed — it's used by Microsoft for backend service communication regardless of what custom domain is set as primary.
• The DNS health dashboard — after records are added, M365 continuously monitors them. A missing or misconfigured record shows up as a warning or error in the DNS health view. This is a live diagnostic tool admins should check after any DNS change and periodically thereafter.

Lab 1-B: Adding, verifying, and configuring a real custom domain

Students complete the full domain verification flow end-to-end using their assigned subdomain under nw7.nat-acc.ca. Every student leaves this lab with a verified, working custom domain and all M365 DNS records in place.

• Step 1 — Initiate domain addition (5 min)
  In the admin centre: Settings → Domains → Add domain. Enter your subdomain exactly as assigned — e.g. lakeviewlogisticsjd.nw7.nat-acc.ca. Click Use this domain. Record the domain name in your Lab Journal.
• Step 2 — Copy the verification TXT record (5 min)
  Microsoft will display a TXT record value unique to your tenant — format: MS=msXXXXXXXX. Copy it exactly. Paste it into your Lab Journal. Do not close this browser tab — you will return to it to click Verify.
• Step 3 — Add the verification TXT record to DNS (10 min)
  Open the DNS control panel for your subdomain. Add a TXT record:
  · Host/Name: @ (root of your subdomain zone)
  · Value: the MS= value from Step 2
  · TTL: 300
  Save the record. Verify in the DNS panel that it appears correctly before switching tabs.
• Step 4 — Verify domain ownership (5 min)
  Return to the admin centre. Click Verify. If it fails, wait 60 seconds and try again — with TTL at 300 it should resolve quickly. Record how many attempts it took and the time elapsed in your Lab Journal.
• Step 5 — Add all remaining M365 DNS records (30 min)
  After verification, M365 displays the full set of required service records. Add each one to your DNS zone. Use TTL 300 for all. Work through them methodically — do not skip any:

• Step 6 — Confirm DNS health (5 min)
  In the admin centre: Settings → Domains → [your domain]. All records should show green within a few minutes. If any show a warning or error, compare your entered value against the expected value in the health view and correct it. Record the final status of every record in your Lab Journal.
• Step 7 — Set as primary domain (5 min)
  In Settings → Domains, select your verified domain and click Set as default. Confirm. In your Lab Journal, note: which domain is now marked as default, and what role does onmicrosoft.com serve going forward?
• Step 8 — Use MXToolbox to validate externally (5 min)
  Open mxtoolbox.com and run an MX lookup against your subdomain. Compare the result to what you entered. Then run a TXT lookup and confirm both your verification record and SPF record appear. This is how you validate DNS from outside the Microsoft ecosystem — a habit worth building.

Reflection & preview

• Ask: "If the MX record priority was set to 0 on a competitor's mail server — what would happen to every email sent to Lakeview Logistics?" — surface the stakes of MX misconfiguration
• Ask: "Your SPF record uses -all. What's the difference between that and ~all, and which is more appropriate for a new organisation still setting up mail flow?" — connect to Week 3
• Quick hands up: who had verification succeed first attempt? Who needed to wait? Normalise propagation delay as a real operational consideration
• Collect exit ticket: for each of the seven DNS records added today, write one sentence describing what breaks if that record is missing or wrong
• Preview Day 3: the domain is live — now it's time to populate it with users. Day 3 covers user creation, licensing assignment, and bulk provisioning